Consistency is one of the primary design goals of database systems. Consistency means that the information stored in the database obeys certain constraints defined for the database.
A DML statement is a modification, such as a deletion, an insertion or an update (or modification), of a single piece of information in a database.
A transaction is a sequence of DML statements that performs a single logical action in a database application.
The 100% principle states: There is one grammar which completely and exclusively prescribes all the permitted information base states and all the permitted information base transitions. This grammar is called the Conceptual Schema.
One requirement that is deducted from the 100% principle is that all updates storing, deleting or modifying information has to be interrupted and checked by a constraint enforcer.
Constraints are a special case of the term “conceptual rules”. Conceptual rules are the rules that prescribe all permitted states and transitions a database can undertake. Conceptual Rules are not limited to testing the legality of data, but also includes computational capabilities. Conceptual Rules should always be obeyed, and they should be “fired” as a result of any database change.
There are two types of Conceptual Rules, rules of static nature and of dynamic nature. Static rules can be checked at any time, while dynamic rules must be checked for each update. E.g. a unique Social Security Number (SSN) for a person can be checked at any time, but a status change from Married to Divorced can only be checked when the status is changed. The present invention mainly relates to constraint enforcers for static rules.
To keep a database consistent at all times, sometimes needs very complex programming.
Some constraints are impossible to implement if they have to be checked per DML statement. One example is the equal constraint. An equal constraint is a rule that says that for a given value in Table T1, the same value must exist in Table T2, and vise versa. If you insert T1 first, the value does not exist in T2 and the insert is rejected. If you insert T2 first, the value does not exist in T1 and the insert is rejected. It is a deadlock situation.
For these kinds of problems, the term Conceptual Transaction has been introduced. It states that at the beginning and end of the transaction, the database must be in a consistent state. During the transaction the database is allowed to be in an inconsistent state. By using a Conceptual Transaction, the above examples become quite trivial.
A Database Transaction is a sequence of DML statements needed for a program to do a certain task. It may be thought of as an envelope with DML statements.
If during the course of a transaction, the Conceptual Rules may be broken, the transaction is referred to as a Conceptual Transaction.
It has been previously observed that it would be sufficient to check all involved Constraints in a Conceptual Transaction for the total database at the end of the transaction. But it was also understood that such an approach would be too time consuming for a practical implementation.
An objective of the present invention is to provide a transaction based constraint enforcer for a database system, a method for enforcing a set of constraints that governs the integrity of information stored in a database, and a database system, which provides a full constraint check facility, satisfying the 100% principle for databases.
Another object of the invention is to provide such a constraint enforcer, a method, and a database system which may be implemented in a simple and efficient way.
A particular object of the invention is to provide such a transaction based constraint enforcer, a method, and a database system, wherein the number of tests that need to be performed at the end of a series of DML statements included in a conceptual transaction does not exceed the number of tests that would have to be performed if the DML statements were not bracketed in a conceptual transaction.
Another particular object of the invention is to provide such a constraint enforcer, a method, and a database system, which includes a transaction based constraint enforcer, wherein conceptual transaction may be implemented in a fashion that allows single DML statements s as well as a transaction comprising a sequence of DML statements.